Asynchronous transfer mode (ATM) and frame relay (FR) are deployed extensively as the broadband backbone and Internet protocol (IP) data backhaul, respectively. One purpose of this deployment is to integrate voice and data communications and provide virtual private network (VPN) services to small- and medium-sized business customers. Network service providers are utilizing in-band signaling mechanisms, such as ATM user-network interface version 4.0 (UNI 4.0). Inherent in these mechanisms is the danger of bypassing traditional protection mechanisms, such as firewalls, and exposing sensitive information to global public Internet networks. Providers are also employing classic IP over ATM, local area network emulation, or multiprotocol over ATM (MPOA) over global networks; all of which further exacerbate these security concerns.
This method of network access from a local IP network into a public ATM or FR backbone involves an entirely new set of threats to the IP infrastructure. While the inherent complexity of ATM and FR protocols makes it difficult to identify all vulnerabilities that may exist and to predict all control plane threats, the following example illustrates one new threat scenario. End system address spoofing provides a simple method for carrying out denial of service and unauthorized information access attacks. Since ATM routing allows multiple routes to a destination, new calls may be routed to the attacker, denying service. Once the call to the attacker is established, the attacker can access the legitimate caller, providing unauthorized access to information. Further, the attacker can force callers to provide their addresses in the call control messages and use this information to spoof their addresses. As a result, security mechanisms at the call control layer are needed to prevent these kinds of attacks.
Existing ATM and FR security mechanisms are tunnel based, i.e., they operate on the network layer, providing reliable transport services to the call control layer and provide secure tunnels between physical interfaces. As a result, they will be referred to as tunnel mode mechanisms. Tunnel mode mechanisms are inherently limited as they cannot provide call control message integrity per virtual interface origin verification or transit network filtering.
The Internet Engineering Task Force (IETF) Internet Protocol Security (IPSEC) Working Group has produced a series of specifications that address various IP security services including authentication, encapsulation, key exchange, encryption algorithms, and their interactions. It has also provided an architectural guideline for network designers in their development of secure IP services.
Included in these IP security services are those that invoke authentication header (AH) methodology to provide control message integrity and origin verification. FIG. 1 illustrates the IPSEC reference model employing both the encapsulation security payload (ESP) 102 and the AH 104 protocols. The ESP protocol also provides message integrity and origin verification security services as well as encryption services. The two protocols can be run independently or in conjunction with each other. By way of examples, FIG. 2 illustrates the use of an AH protocol in an IP packet while FIG. 3 illustrates the use of an ESP protocol in an IP packet. These protocols provide access control and security management. Both AH and ESP can be activated in one of two modes: tunnel mode and transport mode. In tunnel mode, the protocols provide security mechanisms for the IP protocol layer. In transport mode, they provide security mechanisms for the protocol layers above the IP protocol layer (e.g., the Transmission Control Protocol 108 and the User Data Protocol 110 layers).
The IPSEC architecture defines the type and application of, and administrative authority for, security mechanisms. This information is collectively referred to as security service definitions. These service definitions can be entered into the network elements via manual or automated mechanisms. They are stored in a security policy database (SPD). Information in the SPD determines the security constraints on incoming and outgoing packets on a per-interface basis. FIG. 4 is a block diagram illustrating IP transport security associations. As illustrated in FIG. 4, a security association (SA) (items 402 and 404) may be established between two interfaces (items 406 and 408) based on information in the SPD. The SA is similar to the ATM virtual circuit (VC) characteristics, such as forward peak cell rate, in that the SA is unidirectional and only significant to the directly attached interfaces. A given physical interface may have several virtual interfaces, such as multiple network service access point (NSAP) addresses on the user side of a UNI. As a result, each virtual interface will have its own set of SAs. As with any system relying on unique, per-instance security attributes, this system does not scale well for large numbers of virtual interfaces per physical interface; however, as the SA is unique to a physical interface, the set of SAs for a given interface may be stored in individual databases.
The transport mode SA consists of a security parameter index (SPI), an IP destination address, and the security protocol identifier, either AH or ESP. A unique SA is required for each direction and security protocol supported on each interface, e.g., a bidirectional association between peers supporting AH and ESP would require four SAs. The SAs are held in each physical interface's SA database (SAD). This allows the system to apply a specific security policy based on IP address. Both the SPD and SAD must be accessed for all incoming and outgoing traffic. This application of policies ensures that all traffic is scrutinized before forwarding occurs. Use of SAs are well-known in the art (e.g., “Security Architecture for the Internet Protocol,” article by S. Kent and R. Atkinson, IETF RFC 2401, Nov. 1998).
The IPSEC Working Group has also defined a key distribution protocol, Internet key exchange (IKE). IKE is the preferred cryptographic key management service for the ESP security protocol and is used with the security algorithms to provide multiple keys for encryption and authentication. IKE provides automated key management for a dynamic secure operating environment in large, complex networks.
Various embodiments of the present invention utilize one or more of the above described IPSEC features to provide additional security with respect to the call control layer of these signals, and does so in a transport mode. This provides a more robust transport-based security mechanism for providing control plane security for ATM and FR signaling.